\documentclass[11pt,a4paper,spanish,openright,twoside]{report}
\usepackage[spanish,activeacute]{babel}			
\usepackage[utf8x]{inputenc}
\usepackage{supertabular}
\usepackage{multirow}
\usepackage{graphicx}
\usepackage[top=2.5cm, bottom=2.25cm, outer=2.75cm, inner=2.75cm, heightrounded, marginparwidth=2.5cm, marginparsep=0.3cm]{geometry}
\usepackage{emptypage}		%para quitar los encabezados de las páginas en blanco
\usepackage{hyperref}

\usepackage{fancyhdr}		%paquete de encabezados
\pagestyle{fancy}

%%%%% CHAPTERS STYLE %%%%%
\usepackage{fancyhdr}
\usepackage[Bjornstrup]{fncychap}


%contador SQAP
\newcounter{SQAP}	
\newcounter{SQAPii}[SQAP]

%%%%%%% ENCABEZADO %%%%%%
\fancyhead{}
\fancyfoot{}
\fancyhead[RO]{\nouppercase{\rightmark}}	%encabezado de pares: nombre de la sección
\fancyfoot[LE,RO]{\thepage}	%abajo a izqda en pares, derecha en impares: numero de pagina
\fancyhead[LE]{SQAP. Versión \theSQAP.\theSQAPii} %cuadro izquierdo de pagina par: parte y contador
\fancyhead[RE]{\nouppercase{\leftmark}}
\cfoot{ADVSM. Cauchy-Team}
\renewcommand{\footrulewidth}{0.4pt}
\renewcommand{\headrulewidth}{0.4pt}		% linea por debajo del encabezado
\renewcommand{\sectionmark}[1]{\markright{\textbf{\thesection. #1}}}	%negrita

\raggedbottom 

\stepcounter{SQAP}

\begin{document}
\renewcommand{\chaptername}{Apartado}
\ \\
\vspace{6cm}

\thispagestyle{empty}
\begin{center}
\Huge{\textsc{Plan de Calidad \\ del Software}}\\
\small{(Versión \theSQAP.\theSQAPii, \today)}\\
\Large{Cauchy-Team}
\end{center}

\vspace{1cm}

\begin{center}
%\begin{figure}[H]
\includegraphics[scale=4]{logo.png}
%\caption{Casos de uso relacionados con la gestión del almacén}
%\end{figure}

\vspace{0.3cm}

Proyecto para \textsc{Skirta, Sociedad Anónima}
\end{center}

\tableofcontents

% INPUT de la tabla: SQAP_...tabla


\include{GC_PLA_Plan_calidad}


%\chapter{Introducción}


\chapter{Plan de Garantía de Calidad del Software}
Este documento presenta el Plan de Garantía de Galidad (SQA) del proyecto “Advanced Shop Manager (ADVSM)”, desarrollado por el equipo Cauchy-Team.
\section{Propósito}
	
	El Plan SQA tiene como propósito conseguir calidad de software, es decir, que nuestro software cumpla las especificaciones  y requisitos establecidos y satisfaga las necesidades y expectativas del usuario, siguiendo el lema: “Hacer las cosas bien y a la primera”

	Con el fin mencionado, se ha sometido a este plan toda la documentación que hemos ido desarrollando en nuestro proyecto. Por tanto, los elementos cubiertos por el plan SQA son los siguientes:
	\begin{itemize}
		\item \textbf{Documento de casos de uso}, en el cual se exponen los casos de uso del proyecto como primera toma de contacto con las características de la aplicación. 
		\item \textbf{Especificación de requisitos software}, que establece las bases para el desarrollo de la aplicación, luego está dirigida a sus desarrolladores.
		\item \textbf{Plan de proyecto}, que recoge la organización del esfuerzo que realiza cada miembro del equipo durante toda la vida del proyecto. Este documento se verá sometido a más controles de calidad, ya que su contenido se va especificando y ampliando durante el transcurso del proyecto.
		\item \textbf{Plan de reducción, supervisión y gestión del riesgo}, en el cual se realiza un estudio de los riesgos identificados que pueden presentarse durante el proceso de ingeniería de software y el cómo prevenir y enfrentarse a ellos.
	\end{itemize}
	El Plan SQA se realiza sobre todas las actividades asociadas al desarrollo de nuestro software, y continúa registrando cambios durante toda la vida del proyecto, es decir, hasta que el proyecto se vea como entregado y durante la fase de mantenimiento del software, en otras palabras, hasta que el software quede en desuso. Por tanto el Plan SQA abarcará todas las fases del ciclo del proyecto.
	
\section{Documentos de Referencia}
	Se ha utilizado \emph{IEEE 730-2002 - Standard for Software Quality Assurance Plans} para la elaboración del presente documento.
	
	Se hacen referencias a los siguientes documentos:
	\begin{itemize}
		\item Documento de casos de uso
		\item Especificación de requisitos software
		\item Plan de proyecto
		\item Plan de reducción, supervisión y gestión del riesgo
		\item RTF
		\item Actas
		\item Glosario		
		\item Estándares del IEEE que se especifican en la 
sección de {Estándares, prácticas, convenciones y métricas}
	\end{itemize}

\section{Gestión}
	En esta sección se describe la estructura de la organización del proyecto, las tareas relacionadas y sus funciones y responsabilidades.
	\subsection{Organización}
		El grupo SQA es todo el equipo. Debido a la naturaleza del proyecto y al reducido número de miembros que posee, todo el equipo estará encargado de las actividades de Garantía de Calidad.
		
		Lo mismo ocurre de cara al desarrollo. Al ser un grupo tan reducido, todos los integrantes están involucrados de algún modo en el desarrollo.
		
		La calidad del software se verá controlada por los miembros del equipo Cauchy-Team, e influida por los miembros de otros equipos como Grupo Diedral, Nameless y PiKey Team, puesto que han actuado como correctores a través de Revisiones Técnicas Formales (RTF). Cabe mencionar que el equipo revisor ha estado compuesto por miembros de otros equipos debido a lo didáctico de este proyecto.
	\subsection{Tareas}
		El conjunto de actividades que se realizarán para asegurar la garantía del software son las \textbf{revisiones técnicas formales} y \textbf{reuniones periódicas de control de trabajo}.

		En la primera, un equipo corrector externo revisará la documentación hasta el momento y emitirá un informe indicando si el material es correcto o no. Si el informe es favorable, se considerará la inclusión de dicho material en la línea base del proyecto.	
		Las RTFs realizadas sobre los documentos del proyecto son llevadas a cabo por el resto de equipos  desarrolladores del grupo de Doble Grado en Informática y Matemáticas de la UCM. Estas reuniones producirán un acta y un documento adjunto precisando los cambios sugeridos por el equipo corrector. El acta contendrá un breve resumen sobre lo acordado en la reunión  acerca de dichos cambios. Los resultados de estas RTFs se pueden contemplar en los documentos adjuntos de cada una de ellas.
		Por otro lado, de manera menos formal pero no por ello menos importante, se consideran las correcciones del profesor como RTFs sin acta, cuyos cambios son aceptados y corregidos al momento, salvo dudas o preguntas acerca de ellos.

		Respecto a las reuniones periódicas, los miembros de Cauchy-Team someterán a examen los avances en documentación e implementación y establecerán un programa de seguimiento para evitar posibles retrasos, escasa calidad en la documentación u otro tipo de riesgos detallados en el Plan RSGR de este proyecto. En estas reuniones se verificará que el progreso se ajusta al plan de Garantía del Software.
		Para ello, realizamos resúmenes y esquemas de los diferentes estándares que utilizaremos, de esta manera aseguramos que todos los puntos a tratar queden cubiertos. Además, el trabajo de los miembros del equipo encargados de una tarea es supervisado por el resto para detectar mejor posibles errores, y corregido entre el autor y el revisor para una mayor precisión en el contenido de los documentos.
		
		Una mayor descripción de las tareas se incluye a continuación , en forma gráfica:
		%Insértese imagen correspondiente aquí
	\subsection{Roles y responsabilidades}
		Como se mencionó anteriormente, todo el equipo se encargará de las actividades de seguimiento de Garantía de Calidad del Software. Pese a ello, se nombra a Mayra Castrosqui responsable de Garantía de Calidad, creadora de este plan y responsable del mantenimiento del mismo.

		Ella será la encargada de coordinar las reuniones periódicas que se describen en el apartado anterior. Además, gestionará los informes que los auditores externos de RTF emitan. Será cometido suyo que los resultados de dichos informes se apliquen al proyecto, si bien no tendrá porqué ser ella la autora de las modificaciones. Cualquier cambio que nazca por el cumplimiento de la Garantía de Software debe contar con su aprobación.

		El resto del equipo deberá hacer lo posible para que esos resultados repercutan en las actividades del proyecto, siempre bajo supervisión del responsable de Garantía de Calidad.
		
\section{Documentación}
	\subsection{Propósito}
		Antes de listar los archivos que se crearán durante el desarrollo software, es necesario comentar brevemente la naturaleza del proyecto.

		Debido al carácter académico de este desarrollo software, los documentos que se generan pueden no estar en el estricto orden que suele ser normal en este tipo de proyectos, por lo cual es posible que alguno de los documentos que aquí no están debieran estarlo, por ser anteriores a éste.

		Principalmente, el desarrollo estará dirigido por la Especificación de Requisitos Software (SRS), que sirve de base para la creación de la identificación y control de los riesgos, las estimaciones de esfuerzo y la planificación del proyecto.

		Los documentos sujetos a auditoría serán los que se describen en el apartado primero del presente documento.
	\subsection{Requisitos mínimos de documentación}
		Para asegurarnos de que nuestra aplicación de software cumpla con los requisitos técnicos y supere las expectativas de calidad, se requiere como mínimo la siguiente documentación.
		\begin{enumerate}
			\item Descripción de los requisitos de software. El documento \textbf{Especificación de requisitos software} aborda los temas de funcionalidades generales y requisitos básicos necesarios de la aplicación, así como su perspectiva y objetivos, las restricciones del desarrollo y uso (restricciones legales, físicas, de hardware, de capacitación o de implementación). En él, cada requisito aparece identificado de forma única y definida de forma pueda ser objetivamente verificada y validada.
			\item \textbf{Plan de gestión de configuración de software}. Este documento se ha realizado a la vez que el presente Plan SQA, por tanto se verá verificado y validado en la siguiente fase del proyecto.
		\end{enumerate}
		Debido a la naturaleza didáctica de este proyecto, la siguiente documentación se encuentra pendiente de realizarse para próximas entregas.
		\begin{enumerate}
			\item Descripción del diseño del software
			El documento de diseño especifica cómo el software será construido para satisfacer los requisitos establecidos. Describe los componentes y subcomponentes del diseño del software, incluyendo interfaces internas. El diseño se encarga de que la implementación de todo requisito esté contemplada por lo menos en un elemento del diseño, todo sin perder de vista la consistencia de la calidad del producto.

			\item Planes de verificación y validación.
			El Plan de V\&V identifica y describe los métodos utilizados. En la verificación, como su nombre indica, se verifica que (1) los requisitos descritos en la SRS sean aprobados por una autoridad apropiada, es decir, que cumplan con el acuerdo logrado entre el cliente y el equipo; (2) los requisitos descritos en la SRS sean implementados en el
			 diseño expresado en el documento de diseño; (3) el diseño expresado en el documento de diseño esté implementado en código. En la validación, también como su nombre nos dice, se valida que el código, cuando es ejecutado, se adecua a los requisitos expresados en la SRS. El Plan de V\&V se encuentra pendiente de elaboración ya que se necesita de antemano el documento de diseño que se halla pendiente en estos momentos. 
			
			\item Reporte de resultados de verificación y reporte de resultados de validación, que especifican los resultados de la ejecución de los procesos descritos en el Plan de V\&V.
			
			\item Documentación del usuario, donde se especifican y describen los datos y entradas de control requeridos, así como la secuencia de entradas, opciones, limitaciones de programa y otros elementos necesarios para la ejecución exitosa del software.
		\end{enumerate}
	
	\subsection{Otra documentación}
		Otra documentación que será sometida a controles de calidad.
%%%%%%%%%%%% aqui hay un problema con el pdf
		\begin{itemize}
			\item \textbf{Plan de proyecto de software}, elaborado según el estándar recomendado por Pressman, donde se incluyen las  estimaciones de esfuerzo y la planificación. La gestión de riesgos se encuentra en un documento aparte que también será revisado.
			\item \textbf{Plan de reducción, supervisión y gestión del riesgo}, documento en el cual se presentan los riesgos identificados durante el proyecto. Para cada uno de ellos se analiza la probabilidad de ocurrencia así como su severidad, además de planes de contingencia y prevención.
			\item \textbf{Documentación de casos de uso} donde se tomó contacto por primera vez con las características que debe ir adquiriendo el software.
		\end{itemize}

\section{Estándares, prácticas, convenciones y métricas}
		Con el objetivo de perseguir la máxima calidad en la documentación elaborada, se ha procurado seguir el mayor número de estándares reconocidos allí donde ha sido posible. A continuación se listan los estándares seguidos en la redacción de la documentación actual.
		\begin{itemize}
			\item Para la especificación de requisitos software se siguió el estándar \emph{IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Speciﬁcations}.
			\item Para el plan de proyecto se sigue el modelo que Pressman recomienda.
			\item El Plan de Reducción, Supervisión y Gestión del Riesgo se elaboró siguiendo el estándar \emph{IEEE Std. 1540-2001 IEEE Standard for Software Life Cycle Processes - Risk Management}.
			\item Para la Gestión de Configuración del Software se siguió el estándar \emph{IEEE Std. 828-1998, IEEE Standard for Software Conguration Management Plans}.
			\item El presente documento se elaboró siguiendo las directrices del estándar \emph{IEEE Std. 130-2002 IEEE Standard for Software Quality Assurance Plans}.
			\item Para el seguimiento de la calidad por parte de los miembros del equipo, se ha establecido una práctica denominada \emph{Pautas y proceso para el seguimiento de la Calidad del Software}, que todos los miembros de Cauchy-Team conocen, se trata de una guía de uso interno del personal con unas recomendaciones y pautas.
		\end{itemize}
		En cuanto a estándares de documentación, para la escritura de documentos se han definido plantillas para ser utilizadas en la elaboración de entregables. En estas plantillas se definen:
%%%%%%%%%%%%%%%%%%%%%%%%%%%  David debe completar esta parte
		\begin{itemize}
			\item Encabezado: En las páginas pares aparecerá el documento que se está leyendo, así como su versión. Además aparece el apartado actual y su nombre. En las impares aparece el subapartado que se lee y su nombre.
			\item Pie de página: Aparecerá centrado \emph{ADVSM. Cauchy-team} y el número de página.
			\item Fuente y tamaño de fuente para estilo normal: Tipografía \emph{Latin Modern Roman}, 11 puntos.
			\item Fuente y tamaño de fuente para los títulos a utilizar: Tipografia \emph{Latin Modern Roman}, 16 puntos.
			\item Datos mínimos que se deben incluir: Título del documento, fecha, versión y responsables.
		\end{itemize}
		En este proyecto no se han seguido métrica
s de ninguna clase.

\section{Revisiones del software}
	\subsection{Propósito}
		Serán ejecutadas varias revisiones de software con el propósito de purificar las actividades llevadas a cabo para desarrollar nuestro programa. Serán aplicadas en varias etapas del desarrollo del software sobre toda la documentación que va siendo generada. 
		El tipo de revisiones que realizaremos serán Revisiones Técnicas Formales, su objetivo es detectar errores antes de que se conviertan en defectos de nuestro programa, verificar que el software alcanza sus requisitos y garantizar que se está desarrollando según ciertos estándares predefinidos.
		Las RTF se efectuaron mediante reuniones planificadas con miembros de los demás equipos (Grupo Diedral, Nameless y PiKey Team). 
	\subsection{Requisitos mínimos}
		Hay una serie de revisiones mínimas que deben producirse para garantizar un nivel aceptable de calidad. Veremos aquí las revisiones hechas por miembros de los equipos antes mencionados sobre los documentos presentados por Cauchy-Team hasta la fecha correspondiente. Puede que no todos los documentos requeridos se encuentren revisados. El motivo es que aún no están siendo redactados o aún no han sido finalizados, esto se debe al ritmo de la formación de los equipos incluido Cauchy-Team.
		\begin{itemize}
			\item Revisión de las especificaciones de software. Realizada el 8 de marzo sobre la Especificación de Requisitos Software.
			\item Revisión del diseño arquitectónico. Pendiente de realizar.
			\item Revisión de diseño detallado. Pendiente de realizar.
			\item Revisión del plan de verificación y validación. Pendiente de realizar en la siguiente fase del proyecto.
			\item Auditoría de la funcionalidad, se realiza  antes de la entrega final para verificar que todos los requisitos especificados en la SRS han sido satisfechos. Pendiente para el final del proyecto.
			\item Auditoría física, verifica la coherencia interna del software y su documentación, y su disposición para su entrega final. Pendiente para el final del proyecto.
			\item Auditoría durante el proceso, se verificará la consistencia del diseño incluyendo comparación de código y documentación de diseño, especificaciones de interfaces, comparación de los requisitos funcionales y las implementaciones de diseño, entre otros. Pendiente de realizar.
			\item Revisiones de gestión. Su objetivo es garantizar el cumplimiento del presente plan SQA, por tanto, se encuentra pendiente de realizar.
			\item Revisión del plan de gestión de la configuración software. Pendiente de realizar la revisión sobre el documento.
			\item Revisión post-implementación, se realiza al concluir el proyecto. Por tanto, pendiente.
		\end{itemize}
	\subsection{Otras revisiones y auditorías}
		\begin{itemize}
			\item Revisión del Plan de Proyecto. Realizada el 8 de marzo.
			\item Revisión del Plan de Reducción, Supervisión y Gestión del Riesgo. Realizada el 8 de marzo.
			\item Revisión del documento de Casos de Uso. Realizada el 8 de marzo.
			\item Se encuentra pendiente la revisión de la Documentación de usuario.
		\end{itemize}
	En conclusión, hasta la fecha se han realizado cuatro revisiones, todas ellas se efectuaron en el laboratorio 11 de la Facultad de Informática de la Universidad Complutense de Madrid el 8 de marzo del 2013. Se encuentran adjuntos en un anexo el documento RTF y el acta correspondientes a cada documento revisado.
\section{Pruebas}
	Debido a que el proyecto está más orientado hacia la documentación que hacia el software en sí, y por tanto la implementación no será muy profunda, las pruebas a realizar serán pocas y muy concisas, como se detallan a continuación:
	\begin{itemize}
		\item Comprobación de que todos los elementos visuales de la aplicación se cargan y dibujan su interfaz de acuerdo a lo especificado en la SRS.
		\item Comprobación de que los tiempos de respuesta especificados son los obtenidos en la realidad.
		\item Para cada requisito que se acabe implementando, comprobar que las entradas especificadas producen las salidas esperadas. 
	\end{itemize}
\section{Informe de errores y acciones correctoras}
	Todo lo relacionado con posibles errores y sus medidas de solución está especificado en el documento de gestión del riesgo, que contempla detección, solución, y monitorización de problemas tanto en el software creado como en la documentación producida.
	Los informes de error estarán bajo los puntos “Monitorización”, y las acciones correctoras en “Mitigación” y “Acción de contingencia” de cada posible riesgo.
	Las correcciones de errores en los respectivos documentos serán responsabilidad de sus autores, a menos que se especifique lo contrario en el RSGR.
\section{Herramientas, técnicas y metodologías}
	Se ha utilizado Google Drive y el editor de texto Notepad++ como herramientas software para la realización del Plan SQA.
	Además, de cara a la producción de un mejor proyecto, se han incorporado RTFs de equipos externos, así como revisiones internas de los documentos, realizadas respectivamente por autores de otros, para así poder a la vez conocer el ámbito completo de trabajo y abordar cada tarea con una perspectiva diferente, corrigiendo y mejorando los documentos.
\section{Control de medios}
	Debido al nivel de abstracción de la implementación, no existen apenas medios con los que tratar, ya que éstos van empaquetados en el archivo binario con el que se trabaja. Cualquier cambio realizado en los mismos es inmediatamente guardado en el servidor DropBox, de manera que cualquier fallo en nuestros sistemas está respaldado.
	De cara a los datos producidos para el manejo de la aplicación por parte del cliente, se trabajará en todo momento sobre ficheros temporales, produciéndose el volcado a los ficheros permanentes sólo en los momentos de guardado de los datos.
\section{Control de proveedor}
	Debido a que todas las herramientas necesarias para realizar este proyecto son proporcionadas por la universidad, no se considera necesario hacer controles de los proveedores, al suponer una disponibilidad continua por parte de la UCM de sus servidores, que en caso contrario debería ser suplida por el profesor o departamento encargado de la asignatura.
\section{Colección de registros, mantenimiento y conservación}
	Gracias al pequeño tamaño de la información generada, y al amplio espacio disponible en los servidores de nuestros repositorios de Google Code, podemos asegurar tener cualquier versión de cualquier documento realizado en el proceso de desarrollo del proyecto, incluidos archivos eliminados, modificados, o creados en cualquier instante, con comentarios de los autores indicando qué falta o qué se añadió en cada versión.
	
	El período de conservación de los mismos queda a elección del cliente, aunque se prevé un largo período de conservación debido al carácter académico del proyecto y a la legislación vigente sobre permanencia temporal de este tipo de documentos.
\section{Formación}
	Todos los integrantes del equipo deben haber recibido la formación suficiente de Ingeniería del Software en cada momento del proyecto para poder producir la documentación necesaria requerida en dichos momentos.
	En algunos casos puede ser necesaria la consulta a través de internet de datos que hicieran falta para la generación de la documentación por ser difusos o insuficientes en el material de la asignatura.
	
	Por otro lado, para la implementación del proyecto es necesario cursar la asignatura “Fundamentos de Programación” previamente al comienzo del desarrollo, así como “Tecnología de Programación” ya sea previamente al desarrollo o en paralelo, dado que proporcionan los conocimientos necesarios para comprender y realizar las partes del proyecto referidas al producto software final.
\section{Gestión del riesgo}
	Ver el documento de riesgos.
\section{Glosario}
	Ver el documento de glosario.
\section{Procedimiento de cambio e historial del plan de SQA}
	Un historial completo de las versiones de este documento puede consultarse en las primeras páginas del mismo.
	Cualquier cambio que se realice en el mismo será al menos revisado por dos integrantes del equipo desarrollador, asegurando de esta manera la inexistencia de incoherencias o errores.
			
\end{document}
